IP Multimedia Subsystem (IMS) is a standardised and established architecture for delivering IP multimedia services to end users. IMS is to a large extent agnostic concerning the access network used by the end users: access networks may be wireless or fixed line. In the context of IMS, it is important to allow end users to seamlessly move between access networks and access technologies, e.g. to allow voice and video call continuity during such movements.
3GPP TS 23.237 v11.4.0 specifies Single Radio Voice Call Continuity (SRVCC) as a functionality defined for the Long Term Evolution (LTE) architecture to allow voice and video calls to be transferred or “handed over” from the LTE packet switched (PS) domain to a legacy circuit switched (CS) domain, in the case where a mobile terminal has only a single radio interface available to it. Such a transfer might be required, for example, when a call is established by a user terminal over a packet switched (PS) LTE connection and it becomes necessary, due to a deterioration in the LTE radio quality, to transfer the call to a 3G UMTS circuit switched (CS) connection. FIG. 1 illustrates schematically the reference architecture for SRVCC (using the Access Transfer Control Function, ATCF, enhancements).
SRVCC relies upon a network (LTE) determination that a PS to CS handover for a given UE is required. The UE is instructed to perform the handover by way of a (SIP) message sent to it over the PS access (i.e. over the Gm interface), and as a result disconnects from the PS access and connects instead to the CS access. A serving MSC within the CS network is caused to send a setup signal to the UE over the now established CS access in order to establish a CS voice call between the UE and the MSC, whereupon the call is transferred to the CS access. A special case arises when handover is required at the call terminating side during the call alerting phase, i.e. after an INVITE has been received by the UE but prior to the user answering the call. This special case is considered in 3GPP TS 23.237 v11.4.0 section 6.3.2.1.4c.
3GPP TS 23.237 also specifies Dual Radio VCC (DRVCC) as a mechanism analogous to SRVCC but concerned with mobile terminals that have dual radio interfaces, i.e. radio interfaces that can be used in parallel. As with SRVCC, DRVCC makes provision for handover of a voice or video call from a PS to a CS access following call establishment. [In contrast to SRVCC, a determination to perform such a handover in the case of DRVCC is made by the UE rather than within the network.] However, the DRVCC specifications have not previously provided a means to handle a PS to CS handover during a voice or video call alerting phase and in particular have not addresses the call terminating side case.
In the context of DRVCC, FIG. 2 illustrates a possible mechanism for handling PS to CS handover of a voice or video call at the call originating side, during the alerting state. An originating user UE-A sends an INVITE towards a terminating user (not shown) and receives a Ringing response: this exchange uses the PS access. At this point, UE-A determines that the quality of the PS access is not suitable for the call, and a DRVCC process is initiated by UE-A in order to transfer to a CS access. UE-A sends a setup request, via the CS access, to the MSC on the originating side. The request includes a Session Transfer Number (STN), a number statically configured on the UE which is used to route the transfer to the SCC AS. The MSC in turn sends an INVITE to the SCC AS (serving UE-A), with the STN being included within the INVITE. [NB. FIG. 2 assumes that the MSC comprises some interworking function able to provide interworking between the IMS side and the CS signalling side.] The SCC-AS uses the STN contained within the INVITE to detect that the request is a request to transfer the session from PS access to CS access, and uses additional information in the signalling (such as the calling party number) to correlate the transfer request with the INVITE previously sent over the PS access. As a result of sending the INVITE, the MSC knows to expect an Answer. When the Answer is received from the SCC AS, the MSC sends an Answer to UE-A and call set up over the CS access proceeds as usual.
FIG. 3 illustrates a problem that might arise when handling DRVCC on the terminating side during a call alerting phase. In this case, the called party, UE-B, which is initially connected to a PS access, receives an INVITE from UE-A, and sends a Ringing response. At this point, UE-B determines that the quality of the PS access is not suitable for the voice call, and a DRVCC process is initiated by UE-B in order to transfer to a CS access. UE-B then sends a Setup message (standard CS signalling) to the MSC to initiate the transfer. The MSC reacts to the Setup message by sending an INVITE towards the SCC AS. [NB. The MSC may alternatively use CS trunk signalling, e.g. ISUP, in which case the trunk signalling setup message will be routed via a Media Gateway Controller]. At this point, the MSC is awaiting an Answer from the remote end, i.e. from the SCC-AS. In the event that a user answers at UE-B, causing an Answer to be sent to the MSC, this unexpected answer causes an error case to arise at the MSC due to un-matched states existing at UE-B and the MSC.
Whilst it would be possible to solve this problem by introducing new logic into the MSC, this is in practice difficult to achieve due to the large number of already deployed MSCs. A preferred solution is one that involves modifications at only the mobile terminals and the SCC-AS. On the one hand, it is relatively easy to upgrade and deploy terminal software whilst on the other relatively few SCC-ASs have been deployed and it will be a relatively easy task to update those ASs.